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I.  SPLICE  AND  TEE  DATA  DICTION AH Y/DIR ECTOR Y  SYS TEH 

A.  BACKGROUND 

The  purpose  of  the  Stock  Point  Logistics  Integrated 
Communications  Environment  (SPLICE)  is  to  provide  an  envi¬ 
ronment  to  effectively  and  efficiently  support  the  interac¬ 
tive  and  telecommunications  requirements  of  all  current  and 
new  projects  operating  within  the  Navy  Uniform  Automated 
Data  Processing  System  for  Stock  Points  (UADPS-SP).  The 
Naval  Supply  Systems  Ccmman d '"^(NA VSUP)  is  the  projecr  sponsor 
for  SPLICE  with  the  UADPS-SP  sites  beina  the  primary  users 
along  with  ether  Department  of  Defense  (DoD)  /  Navy  systems. 
[Ref.  1] 

NAVSUP  initiated  the  SPLICE  project  to  consolidate  the 
telecommunications  requirements  of  several  different 
projects,  in  various  stages  of  design,  which  will  impact  all 
cf  the  Navy  UADPS-SP  sites  [Ref.  2].  (See  list  of  projects 
which  follows  this  section.)  Implementation  of  SPLICE  is 
expected  tc  provide  the  following  capabilities: 

•  sign-on  security 

•  CET/terninal  management 

•  screen  formatting 

•  edit,  validation  and  correction 

•  fault-tolerant  operation 

•  data  communications  front  end 

•  processing  with  menu  capability 

•  interactive  transaction  entry 

•  access  to  database  management  systems 

SFLICE  will  consolidate  the  telecommunications  network 


with  a  standard  suite  of  hardware  and  software. 


The  SPLICE 


concept  involves  the  use  of  a  single  minicomputer  hardware 


and  software  suite  in  conjunction  with  the  existing  UAOPS-S? 
Burroughs  system.  The  SPLICE  minicomputers  are  intends!  ro 
absorb  and  contain  the  communications  handling  workload  that 
is  currently  forcing  the  host  Burroughs  CPU’s  into  satura¬ 
tion.  The  SPLICE  concept  calls  for  standard  minicomputers 
to  be  employed  as  foreground  processors  at  each  UADPS-S? 
site  and  interfaced  via  a  high  speed  data  network  (HSDN)  tc 
the  Burroughs  medium  size  system.  The  foreground  minicom¬ 
puter  will  handle  communication  lines  and  terminal  manage¬ 
ment,  support  interactive  operations  and  stage  messages  for 
the  background  processors.  The  Burroughs  background  systems 
will  handle  large  file  processing  applications,  report  prep¬ 
aration,  batch  processing  and  data  base  management 
functions. 

SPLICE  will  utilize  a  standard  minicomputer  and  a 
modular  software  design.  A  modular  sat  of  embedded  computer 
software  components  will  provide  flexibility  in  that  the 
configuration  of  each  site  within  the  SPLICE  network  can  be 
designed  tc  meet  its  unique  requirements.  The  SPLICE 
ccn  figuration  will  consist  cf  multiple  processors  with 
shared  resources.  A  SPLICE  configuration  may  interface  with 
one  or  mere  mainframes,  function  as  a  satellite  off  another 
SPLICE  complex,  or  function  as  a  stand  alone  system 
fBef.  3].  Within  the  SPLICE  network,  each  terminal  and 
computer  process  in  the  system  can  potentially  access  any 
ether  terminal  and  computer  process. 

A  common  element  within  the  SPLICE  system  is  the  use  of 
CRT's  to  provide  interactive  processing  capabilities  for  a 
"user  oriented  system."  The  CRT  display  terminals  will 
interact  with  the  application  logic  and  fetch  information 
from  system  data  bases.  The  current  stock  point  system  dees 
not  support  interactive  processing  nor  dees  it  have  the 
capacity  tc  add  a  najor  increase  in  terminal  support  or 
associated  crocessing  requirements. 


The  design  philosophy  reinforced  throughout  the  SPLICE 
project  eill  be  device  independent  management  capability. 
No  application  program  will  read  or  write  directly  to  or 
from  a  particular  device.  The  driving  force  behind  the 
SPLICE  project  is  the  need  to  provide  computer  and  communi¬ 
cations  interfaces  for  the  many  application  initiatives 
which  cress  boundaries  of  tasking  and  funding  of  many  Navy 
major  claimants  [8ef.  2].  Projects  that  are  to  be  tied  to 
OADPS-S?  under  the  SPLICE  project  are: 

•  Automation  of  Procurement  and  Accounting  Data  Entry 
(APADE) 

•  Centralized  Accounting  and  Billing  (CAB) 

•  Closed  Loop  Aeronautical  Management  Program  (CLAMP) 

•  Disk  oriented  Supply  System  (DOSS) 

•  Fixed  Alllowance  Management  and  Monitoring  System 
(FAMMS) 

•  Financial  Improvement  Program  (FIP) 

•  Integrated  Disbursing  and  Accounting  (IDA) 

•  Multiple  Activity  Processing  System  (MAPS) 

•  Management  information  System  International  Logistics 
(HISIL) 

•  Navy  Automated  Transportation  system  (NATDS) 

•  Navy  Automated  Transportation  Documentation  System 
(NAVADS) 

•  Navy  Standard  Civilian  Payroll  System  (NAVCIPS) 

•  Cn  Line  Autodin  (OLA) 

•  Operating  Target  Accounting  for  TRIDENT  (OPTAR) 

•  Receipt  Improvement  Project  (RIP) 

•  TRIEENT  submarine  Logistics  Data  System  (TRIDENT  LDS) 

•  Requisition  Monitoring  and  Material  Expediting  (RM8ME) 


B.  NATOBE  CF  THE  PHCELEM 


Research  and  thesis  work  cn  the  SPLICE  project  thus  far 
has  primarily  emphasized  telecommunications  and  local  area 
network  (LAN)  design  within  the  SPLICE  project  [Ref.  *]. 
Because  of  *he  nature  of  the  project  and  the  extent  of  its 
future  iupact  on  other  DoD/Navy  systems,  SPLICE  should  also 
he  locked  at  as  an  environment  which  calls  for  the  applica¬ 
tion  cf  a  Data  D icticnary/D irectory  System  (DDS)  to  fullfill 
its  expectations. 


C.  OBJECTIVE 


TANDEM  has  been  selected  as  the  minicomputer  of  choice 
for  the  SPLICE  project.  As  a  result,  the  objective  of  this 
thesis  to  suggest  a  preliminary  DDS  design  for  SPLICE  based 
Upon  the  TANDEM  DBMS. 

D.  HETHCDOIOGY 

This  thesis  will  look  at  the  current  state  of  the  SPLICE 
EDS  and  what  an  active  DDS  can  do  for  the  SPLICE  project. 
It  will  lock  at  methods  to  evaluate  a  DDS  and  apply  these  to 
the  ECS  design.  DDS  design  considerations  within  the  SPLICE 
environment  will  be  identified,  such  as  which  resources  need 
to  be  represented  in  the  DCS,  and  to  the  extent  possible, 
integrated  into  the  recommended  proposal.  In  the  process, 
questions  cn  the  distribution  of  the  DDS  within  SPLICE  will 
also  be  addressed  with  recommendations  for  selection  of  the 
format  which  is  most  beneficial  to  the  objectives  of  the 
SPLICE  project. 


V 


II.  DATA  DICTIONARY /PI BECTOBY  SYSTEM  CONCEPTS  AND 

CONS  IDE NATIONS 

A.  INTBCDOCTIOH 

Data  is  a  very  useful  and  necessary  resource  to  an  orga¬ 
nization.  Data  is  a  general  tern  used  to  express  any  or  all 
facts,  numbers,  letters,  and  symbols  that  refer  tc  or 
describe  an  object,  idea,  condition,  situation  cr  ether 
factor.  It  can  be  used  to  influence  management  decisions, 
by  providing  the  manager  with  timely  and  accurate  informa¬ 
tion.  With  these  thoughts  in  mind,  it  is  very  important  that 
data  as  a  resource  be  easily  accessible  for  proper  and 
effective  management. 

The  early  design  of  Navy  data  processing  systems 
revolved  around  specific  application  systems  (UADFS-SP)  , 
hence  the  data  was  organized  so  that  it  would  be  machine  and 
application  specific.  Therefore  the  data  seldom  crossed 
opera ticr.al,  functional  or  organizational  boundaries.  The 
outcome  of  this  early  design  was  multiple  definitions  of  the 
same  data  as  individual/independent  data  files  were 
generated  creating  much  redundancy  and  overlap. 

As  the  role  of  the  computer  has  grown  in  the  Navy  Supply 
System,  the  need/reguiremer.t  for  system  integration  has 
become  evident,  especially  in  the  area  cf  data.  The  intro¬ 
duction  of  Database  Management  Systems  (DBMS)  solves  many  of 
the  information  resource  problems  by  organizing  the  data 
elements  under  consistent  controls  and  structures,  by 
providing  a  single  flexible  facility  for  accommodating 
different  data  files  and  operations,  and  demanding  less 
programming  effort  than  conventional  programming  languages. 


This  centr alizat icn  cf  ccntrcl  is  growing  in  accsp-nr.c® 
and  the  function  of  implementing  this  centralized  control  is 
in  the  hands  of  the  Database  Administrator  (DBA)  [Ref.  5]. 
The  data  administ ration  function  is  responsible  for  -h? 
system  wide  inventory  and  control  of  data.  In  requires 
pertinent  facts  and  relationships  about  the  varying  data 
elements,  processes,  users  and  equipment  to  be  located  in 
the  data-processing  environment  [Ref.  6].  Data  administra¬ 
tion  internal  ccntrcl  procedures  restrict  access  tc  data, 
manage  development  cf  new  types  cf  data,  and  protect  data 
from  erroneous  update  and  system  failure. 

A  software  tool  that  is  used  to  control  and  manage  data 
elements  in  a  uniform  manner  and  is  therefore  an  aid  tc  the 
DBA  is  the  Diet ionary/Direc ter y  System  (DDS)  .  The  DDS  can 
serve  Database  Administrators,  system  analysts,  software 
designers,  and  programmers  by  providing  a  central  repository 
for  information  about  data  resources  across  organization  and 
application  lines.  It  is  a  set  of  one  or  mere  databases 
containing  data  about  an  organization's  information 
resources  which  can  be  retrieved  and  analyzed  using  standard 
database  management  system  capabilities,  (i.  e . ,  query 
languages,  processors)  [Bef.  7]. 

The  range  of  information  which  can  be  held  in  a  DDS  is 
very  large.  The  simplest  system  may  only  hold  sufficient 
information  to  document,  say,  COBOL  file  structures.  The 
mere  complex  systems  may  hold  design  requirements,  designed 
database  structures,  possible  future  structures,  operational 
information,  extensive  details  cf  access  to  data,  and  even 
retwerk  specifications.  Such  complex  systems  initially 
build  around  data  structure  recording  facilities,  tut  once 
developed,  are  really  the  data  processing  departments'  own 
database  [  Bef.  8  ]. 

The  primary  advantages  of  a  well  designed  DDS  which  are 
applicable  to  SPLICE  are: 


•  It  contains  a  unique  identification. 


a  set  of  physical 
characteristics,  and  a  textual  description  for  each  of 
the  data  elements. 

•  It  shows  the  relationships  of  elements  to  each  ether, 
and  tc  components  of  the  system. 

•  It  specifies  the  source,  location,  usage  and  destina¬ 
tion  of  the  elements. 

•  It  has  validation  and  redundancy-checking  capabilities. 

•  It  contains  security  safeguards  to  control  the  accessi¬ 
bility  to  the  data  elements. 

•  It  has  a  command  language. 

•  It  has  reporting  capabilities,  such  as: 

-  predefined  management-oriented,  statistical  or 
summary  reports 

-ad-hoc  user-defined  reports 

-cross-reference  reports 

-elements  usage  reports 

-audit  trail  reports 

-change-effect  reports 

-error  reports 

•  It  has  retrieval  capabilities,  such  as  keywording, 
indexing,  and  online  queries. 

•  It  has  facilities  for  interacting  with  a  DBMS  [Hef.  5]. 
A  DDS  would  be  useful  tc  SELICE  as  a  documentation  tocl. 

Within  the  appiica tiers  environment,  analysts  and  users  of 
the  CCS  would  be  reguired  tc  define  system  data  definitions 
and  records  as  well  as  other  elements  of  the  dictionary.  In 
the  process,  old  definitions  would  be  updated,  outdated 
definitions  would  be  discarded  and  new  definitions  would  be 
input.  Redundancy-checking  capabilities  would  prevent  two 
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elements  frcm  having  different  descriptions.  Use  of  a  CDS 
would  enforce  establishment  of  standard  data  definitions  and 
descriptions  for  these  applications  programs  used  by  the 
SPLICE  system. 

Hhen  the  DDS  has  teen  designed  and  is  part  of  the  SPLICE 
system,  it  could  serve  as  an  important  basis  for  the  future 
development  of  projects  tied  to  UADPS-SP.  By  cataloging 
data  requirements  resulting  from  requirement  analysis  activ¬ 
ities  [Hef.  9],  the  DCS  becomes  an  aid  in  the  development  of 
new  programs.  Eventually,  the  DDS  for  SPLICE  could  facili¬ 
tate  conversion  of  the  present  file-oriented  application 
system  to  a  DBMS-oriented  system  when  the  DBMS  becomes 
available. 

The  key  aspect  cf  a  DDS  is  that  it  provides  resource 
independence.  Resources  are  protected  from  changes  in  other 
resources.  Modifications  or  changes  may  be  made  within  the 
CDS  and  this  would  net  necessitate  changes  in  the  applica¬ 
tions  pregrams.  Conversely,  changes  in  the  applications 
programs  would  net  necessitate  modifications  of  the  DDS  data 
entities.  In  a  distributed  environment,  this  resource  usage 
flexibility  is  particularly  advantageous.  Uniformity  in 
resource  description  standards,  enforced  by  a  SPLICE  DDS, 
would  enable  a  smoother  and  more  convenient  interface  of 
large  application  systems  like  APADE  and  UADPS-SP  (Ref.  7], 

E.  PASSIVE  AHD  ACTIVE  DDS 

DDSs  can  be  grouped  according  to  whether  their 
dicticnary/directory  function  is  active  or  passive. 
Further,  DDSs  can  be  subdivided  into  free-standing  (indepen¬ 
dent)  or  dependent  depending  on  their  implementation.  Iakl6 
I  presents  a  schematic  representation  of  this 
classification. 


TABLE  I 

DDS  Functional  Classifications 


SOFTWARE  TOOL 

FUNCTION 

IMPLEMENTATION 

free-standing 

DOS 

ACTIVE 

DEPENDENT 

PASSIVE 

DEPENDENT 

1 ....  -  _  _ 

1 

_ 1 

A  passive  DDS  is 

a  software 

package  that 

dees  not 

require  that  the  processes  cr  system  components  depend  on 
the  DDS  fcr  their  data.  In  its  simplest  form,  a  passive  DDS 
cnlv  registers  the  data  elements  for  programs  and  processes 
on  an  after-the-fact  basis  as  a  documentation  facility. 
Passive  EDSs  usually  are  embedded  functions  within  another 
system,  serve  as  the  data  and  file  pre-definition  mechanism, 
and  are  an  integral  physical  part  of  another  system.  since 
the  passive  DDSs  are  embedded  within  another  system,  they 
are  necessarily  oriented  towards  the  characteristics  and 
internal  representation  of  that  system. 

An  active  DDS  is  a  separate  and  distinct  software 
package  that  functions  mainly  as  a  tool  for  identifying, 
locating,  controlling,  reporting,  and  manipulating  the 
information  about  data  elements  in  a  database.  It  is  a 
basic  tool  within  the  database  environment  that  can  assist 
the  data  administrator,  the  system  analysis/designer,  and 


the  programmers  m  managing,  planning,  and  evaluating  th- 
collecticn,  storage,  and  usage  of  the  data  resources.  DDSs 
are  said  to  be  active  with  respect  to  a  program  or  process 
if  and  only  if  that  program  or  process  is  fully  dependent 
upon  the  DDS  for  its  data  [  Hef .  5]. 

The  existence  of  active  DDSs  as  separate  er.titites 
rather  than  as  a  part  of  another  system  is  a  recent  innova¬ 
tion  in  the  area  of  data  management.  They  may  be  imple¬ 
mented  in  such  a  way  that  they  require  a  DBMS  to  function 
consistently.  A  further  subdivision  of  DDSs  tends  to  make 
clear  the  implementation  of  these  packages.  They  are  free¬ 
standing  (independent)  or  dependent.  A  point  that  needs  to 
be  made  is  that  both  cf  these  divisions  function  principally 
as  DDSs,  and  they  are  different  only  in  their 
implementation. 

The  major  differences  between  an  active  and  a  passive 
DDS  are: 

•  The  active  DDS  is  a  self-contained  system,  whereas  the 
passive  dds  is  an  internal  function  of  another  software 
system. 

•  The  reporting  and  retrieval  capabilities  are  extensive 
for  the  active  ECS,  and  modest  for  the  passive. 

•  Active  DDSs  have  more  extensive  security  control  over 
the  data  elements. 

1  •  Free-standinc 

Free-standing  DDSs  are  self-contained,  and  perform 
the  basic  functions  of  controlling  and  managing  the  data 
elements  without  dependence  cn  a  DBMS.  However,  they  may 
use  programs  not  specifically  written  for  the  DDSs  in  order 
to  enhance  their  capabilities  and  performance.  A  DDS  that 
is  free-standing  may  support  one  or  more  DBMSs  through  the 
use  cf  interfaces,  achieving  mutual  benefit  from  this  asso¬ 
ciation.  It  should  be  emphasized  that  the  free-standing  DDS 
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does  rot  depend  on  tie  DBMS  tc  function  but  the  us*  of  DBMS 
interfaces  can  provide  the  database  administrator  with  a 
greater  degree  of  control  over  the  DBMS.  It  is  even 
possible  for  free-standing  DDSs  to  have  interfaces  tc  mere 
than  one  DBMS  simultaneously.  Free-standing  DDSs  are  also 
known  as  Generalized  or  Independent  DDSs  [Ref.  5], 

2.  Deper.den  t 

The  dependent  DDSs  are  separate  software  systems 
that  are  specifically  tailored  to  a  general  purpose  DBMS. 
They  provide  the  DBMS  with  control  and  management  cf  the 
data  elements  by  supplying  the  DEMS  with  the  descript  ions , 
definitions,  locations,  and  cross-references  of  the  data 
elements.  In  turn,  DBMS  resources  such  as  file  structure 
and  access  methods  are  made  available  to  the  DDS.  Because 
the  dependent  DDS  is  designed  and  implemented  tc  be 
DBMS-specific,  the  portability  of  this  type  of  DDS  is 
restricted  to  installations  having  that  particular  DEMS. 

C.  SOFTWARE  IRTERFACES 

The  software  interface  provides  a  formatted  pathway, 
enabling  the  DDS  to  provide  a  set  of  data  attributes  to 
other  software  systems  such  as  compilers  and  Data  Definition 
language  (DDL)  processors  and  enabling  these  systems  to 
retrieve  and  update  information  in  the  DDS  either  statically 
cr  dynamically  [Ref.  6]. 

The  static  interface  links  the  DDS  with  another  system 
indirectly  via  the  extraction  of  a  file  of  formatted  data. 
For  example,  the  DBA  enters  into  the  DDS  all  pertinent 
transactions  to  describe  the  database.  After  reviewing  the 
accuracy  of  this  database  description  the  DBA  activates  a 
DDS  command,  say  GESERATE,  that  uses  this  description  to 
provide  a  file  containing  DDL  translates  this  generated  DDL 
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into  a  schema  file  that  the  run-time  unit  of  the  DBMS  can 
access. 

Static  interfaces  differ  depending  upon  whether  t fcev 
interface  the  DDS  with  user-written  programs  cr  with 
vendcr-s cpplied  software  packages.  Static  interfaces  for 
programs  written  in  languages  such  as  COBOL  and  PL/1  produce 
file,  record,  and  database  descriptions  for  the  user 
programs  frcm  the  DDS.  These  interfaces  feature  edit  capa¬ 
bilities,  format  options,  and  various  other  functions  to 
make  the  interface  mere  flexible.  Static  interfaces  for 
software  packages  such  as  DDL  processors,  communicat ior. 
monitors,  and  query  processors,  produce  formatted  statements 
for  these  packages  or  create  specially  encoded  control  files 
for  their  use.  The  options  for  customizing  the  interface 
with  these  types  of  software  packages  are  more  limited  than 
are  the  options  provided  for  interface  with  user-written 
programs.  Also,  tbese  packages  generally  have  more  rigid 
language  formats  and  the  interface  statements  are  usually 
used  only  by  the  DBA  (Hef.  6]. 

Static  interfaces  are  prevalent  because  of  their 
utility,  compatibility  and  efficiency.  The  static  DDS  can  be 
made  compatible  with  many  versions  of  other  software  pack¬ 
ages  (i. e, several  different  CEMS's)  and  can  be  developed 
independently  of  the  source  cede  of  particular  software 
packages.  A  disadvantage  to  the  user  of  a  str.ic  interface 
is  the  extra  effort  that  may  be  required  to  generate  and 
catalog  data  for  the  CDS.  Plus,  the  static  interface  itself 
has  no  capability  of  updating  the  data  of  the  system  with 
which  it  interfaces  and  therefore  data  in  other  systems  can 
become  inconsistent  with  data  in  the  DDS. 

Dynamic  interfaces  provide  direct  access  of  the  DDS  to 
ether  software  modules.  This  direct  access  is  commonly 
achieved  by  high-level  interface  commands  that  shield  the 
software  package  frcm  the  physical  details  of  the  DDS. 
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Dynamic  :r.itr:ac;S  prevail  cor.sas  .arcy  ccntro.  ana  C;;:::.:- 
ties  for  both  upiats  2nd  retrieval.  changes  tc  *h3  DD~  ar* 
auto matica lly  reflected  ir.  *h=  next  execution  of  arc;  soft¬ 
ware  packages  ho  which  the  DCS  is  interface  1.  A  scf*var* 
packags  car.  directly  retrieve  ana  update  data  stored  ir  the 
DOS .  ?cr  example,  a  COBOL  preprocessor  can  retrieve  file 
d«--scriDt ions  from  the  DD5  and  uodate  the  DDS  to  reflect  the 


compilation  date  ir.  the  identification  of 
.'7.  All  requests  bv  software  oackaaes  for 
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routed  through  the  DCS  by  a  dynamic  interface  function,  sc 
the  security  and  validity  checks  of  the  DDS  are  always 
applied  [Ref.  6]. 

Use  cf  a  dynamic  interface  incurs  significant  overhead 
due  to  the  sire  and  complex  structure  of  th°  DDS. 
Application  development  support  aids,  such  as  pr epre cesscrs, 
source  program  managers,  and  design  aids,  Generally  can 
afford  this  overhead  because  response  time  is  not  critical 
but  on  the  other  hand,  efficiency  is  critical  for 
transaction-processing  systems  (i.e.  a  query  processor)  that 
reference  the  DDS.  Tc  reduce  the  potential  overhead,  common 
queries  may  be  precompiled  and  stored  in  t DDS  or  the 
software  packages  can  retrieve  all  the  data  required  for  a 
transaction  at  once  and  therefore  future  accesses  for  this 
transaction  become  memory  lockups. 


E.  CCNIIBT  FUNCTIONS 

The  integration  of  a  DDS  into  its  environment  is 
provided  by  convert  functions.  These  functions  alleviate 
some  cf  the  problems  encountered  in  initially  populating  a 
EDS.  The  convert  functions  cf  a  DDS  scan  source  programs, 
database  descriptions,  ar.d  teleprocessing  environment 
descriptions  and  automatically  produce  maintenance  trans¬ 
actions.  The  DBA  will  stall  have  to  scrutinize  these 
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g -r  a  rallr; d  *r  for  thri  pc  ssibilio  y  cf  r  t  ;  :  cao  c 

ar.d  rcr  "a:. car  i  entries.  Ar.  example  would  be  if  oh-  7-  .1:.  t 
ccnvo  ncicr.s  used  in  source  programs  ar  a  urcroor 0 11  - c,  Ian 
ore  LEA  will  find  if  necessary  tc  c.o~  ngr  d-oails  ir.  -.any  of 
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Ccr.  v  arc  functions  are  offered  to  oor.verc  ia^a  fro.?.  both 
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significant  characteristics;  1)  aha  contort  cc  th-  generated 
transacoicr.s,  2)  the  input  file,  3)  aha  command  options,  and 
4)  *he  source  program  analysis.  The  data  dicaicnary  mainte¬ 
nance  transactions  thaa  are  created  by  convert  functions 
usually  also  contain  the  re lat ion ships  bee  wear.  data  entities 
(i.s.,  between  a  record  and  an  element)  and  most  language 
clauses.  For  example,  ®lem~na  arar.sacticns  generated  by  a 
CO 30 1  convert  function  capture  data  for  th 2  DDS  from  aha 
program’s  OCCURS,  PICTURE,  and  USA 33  clauses.  A  convert 
function  is  considered  to  be  equivalent  if  the  DDS  can 
regenerate  ahs  input  source  data  description  from  the  DDS 
data.  The  ability  to  analyze  the  data  of  source  programs 
can  make  th*  DDS  a  valuable  tool  for  auditing  adherence  to 
software  control  techniques.  The  DDS  car.  detect  and 
disclose  inconsistencies  in  the  names,  formats  and  clauses 
(comments,  initial  values)  of  the  record  definitions  used  in 
several  programs  and  the  corresponding  standard  record 
definitions  in  the  DDS  ( Hef .  6]. 

E.  IN  VI  BCD  KENT  AL  DEFESDEHCT 

The  environmental  dependency  characteristic  of  a  DDS  is 
determined  by  its  reliance  on  a  specific  hardware 
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he  DBMS  for  data  management  services  and  rh®  scare 


c.  D  EM5  .cr  data  management  services  and  tr.®  source  or 

data  used  by  the  DBMS  for  access  to  stored  databases.  The 
:  ■  c  r  ®  *  of  environmental  dso®ndetcy  is  broker.  into 
INDEPENDENT,  D SMS- APPLICATION,  and  Id BSD DSD  approaches. 

In  the  INDEPENDENT  approach,  the  DDS  is  autonomous.  I>.= 
DBMS  maintains  its  own  source  of  data  and  the  DDS  uses  r.cr.e 
cf  the  DBMS  utilities  for  providing  data  dictionary  manage¬ 
ment  functions.  The  benefits  of  this  approach  are  that  it 
makes  the  dictionary  more  portable  and  will  probably  be 
possible  to  use  the  dictionary  cr.  a  variety  of  hardware  and 
operating  system  configurations. 

In  the  DBMS- APPLICATION  approach,  the  DDS  appears  tc  the 
DBMS  as  just  another  database.  The  DBMS  maintains  its  own 
data  for  each  database  and  these  are  separate  from  the  DDS. 
The  OEMS  utilities  provide  most  cf  the  DDS  management  func¬ 
tions,  but  data  is  defined  separately  for  the  DBMS  and  for 
the  DDS.  The  DDS  will  interface  dynamically  with  only  one 
E3MS  and  its  related  components,  but  there  can  be  static 
interfaces  to  other  DBMSs  that  operate  with  the  same 
hardware. 

In  the  EMBEDDED  approach,  the  DDS  is  actually  a  compo¬ 
nent  of  *he  DBMS.  This  approach  provides  complete  integra¬ 
tion  of  the  DDS.  The  DBMS  utilities  provide  the  DDS 
management  facilities  and  the  DBMS  uses  the  DDS  tc  direct 


access  tc  stored  databases.  No  other  internal  directories 
exist  fer  the  DBMS,  and  its  related  components  rely 
completely  on  the  DCS  for  data.  For  example  a  query 
processor  extracts  user  views  from  the  DDS  and  the  DBMS 


applies  integrity  constraints  specif iad  in  the  DPS  c-fcre 
storing  a  data  element. 

The  DBA  needs  to  decide  what  functions  this  powerful 
tool  in  a  database  environment  is  to  perform.  The  z 3 A  will 
have  tc  evaluate  the  pros  and  ccr.s  of  each  function  that  has 
teen  discussed  and  then  weigh  them  according  no  the  relative 
importance  of  each  function  tc  the  DBA's  environ men*.  For 
example,  dees  he  want  the  software  interfaces  tc  link  to 
ether  systems  statically  or  dynamically,  how  much  does  he 
want  the  convert  functions  tc  do  automatically,  what  pricc 
is  he  willing  to  pay  for  this  service,  and  what  reliance 
dees  he  want  the  DDS  to  have  on  the  hardware  configuration, 
an  operating  system,  a  DBMS,  or  a  teleprocessing  monitor? 
Cnee  these  questions  are  answered  the  DBA  must  be  sure  that 
the  functional  requirements  of  his  environment  have  been 
met . 


I.  CCNTINTS  AND  LOGICAL  STBOCTORE  OP  DDS 

A  useful  DDS  will  contain  more  than  merely  information 
about  data.  It  is  desirable  that  the  DDS  represents  such 
system  resources  as  cata,  hardware,  software,  transactions, 
personnel,  and  documents.  Entities,  attributes,  and  rela¬ 
tionships  associated  with  these  resources  are  presented 
below . 

Data  resource  informat icn  should  include  the  following 
entities:  data  elements,  data  groups,  schemas/subschemas, 
records,  files,  and  databases.  Attributes  for  these  enti¬ 
ties  must  be  determined  by  the  anticipated  usage  of  the  DDS. 
[Ref.  6]  suggests  typical  attributes  for  the  data  element 
entity  and  th9se  appear  in  Table  II.  These  attributes  have 
teen  chosen  from  existing  commercial  data  dictionary/ 
directory  systems.  Attributes  for  the  file  entity  have  been 
suggested  in  the  SPLICE  specifications  [Ref.  10],  and  appear 
in  Table  III. 


TABLE  II 

Da-ta  Element  attributes  (from  Allen  et  al  1982) 


Tvpe 
R  ange 
length 

Unit  of  Measure 
Usage 


Languaas  names 
Repetitions 
88  Levels 
Sev 

Default  value 
Display  format 


TABLE  III 

File  Entity  Attributes 

File  name  Format  (seg,  random,  bin) 

locations  Access  control 

Sire  (in  bytes)  Access  security  protection 

.... - - — - - - - .... - - .. - - - - -  i 


Relationships  are  associations  between  one  or  mere  data 
entities  and  are  also  a  function  of  anticipated  usage. 
Figure  2.1  is  a  possible  network  structure  relating  data 
entities.  This  structure,  implemented  in  the  appropriate 
CEMS  would  provide  answers  tc  the  following  queries  via 
conventional  query  languages  and  processors: 

•  "List  the  record  layout  (all  data  elements  and  keys) 
fer  the  Master  Stock  Item  Reference  (MSIR)?" 

•  "What  locations  in  the  network  stock  item 
59C5-00-255-369S,  resistor,  fixed,  composition?” 

•  "What  files  and  records  contain  the  data  element 
NATIONAL- STOCK- NUMBER?" 

•  "Whc  is  the  manufacturer  of  part-number  248W-24-A?" 

24 


*■  m  »  m  *  «  ‘  J  •  ■*  -J* 


ol 


I  SCHEMA  | 
I  I 


j  D  STAB AS  E  | 


RECORD 


GROUP 


ELEMENT 


VALUE 


Figure  2. 1  Logical  Structure  Describing  Data  Resources 
(froa  Scbniadewind  and  Dolk  1983). 


Hardware  entities  and  attributes  identified  in  [Ref.  10] 
have  teen  specified  as  part  of  the  Configuration  Management 
System  (CMS)  for  SEIICE.  A  selective  sample  is  shown  in 
Table  IV.  The  DDS  could  be  of  value  regarding  hardware 
resources  if  it  could  display  topological  information  about 
all  or  part  of  the  SPLICE  network.  One  logical  structure 
which  might  provide  this  capability  within  a  conventional 
CBMS  environment  is  given  in  in  Figure  2.2  [Ref.  7]. 

Possible  queries  might  include: 

•  "Hew  many  terminals  are  located  within  each  LAN?" 

•  "Which  LANs  have  database  processors?" 
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TABLE  IT 

Selected  Hardware  Entities  and  Attributes 


Entities 

Processing  system 
Secondary  storage 
Communications  system 


Attributes 

Type 

Model 

Model  number 
Serial  number 
Mfger’s  number 
Source 


Concentrators 
Termi  nals 

LAM  I/O  peripherals 


Features 
Description 
Docu.  references 
Osage  by  site 
Cost 

Maintenance  activity 


Recommended  software  entities  and  attributes  from 
[Ref.  10]  are  summarized  in  Table  V.  One  possible  logical 
structure  for  software,  transaction,  and  report  entities  is 
given  in  Figure  2.3.  The  advantage  of  this  kind  of  struc¬ 
ture  is  that  one  can  extract  data  flow  information  from  it 
relatively  easily.  Thus  a  query  to  the  effect  of  "construct 
a  data  flow  analysis  (input  files,  modules/transacricns. 
output  files,  reports)  for  the  APADE  system"  should  be 
reasonable  to  implement.  Inclusion  of  these  resources  in 
the  DDS  contributes  greatly  to  the  viability  of  the  DDS  as  a 
systems  analysis  and  design  tool. 

The  EDS  can  catalog  documents  other  than  reports.  A 
summary  of  entities  and  attributes  for  various  kinds  of 
documents  is  shown  in  Table  VI  [Ref.  10]. 

Personnel  is  another  resource  which  can  be  represented 
in  a  EDS.  Information  about  users,  account  numbers,  and 
access  authority  may  have  important  impacts  on  security 
considerations.  DBAs  could  find  it  useful  to  have  access  to 
data  about  programmers,  analysts,  and  the  programs/systems 
which  they  are  responsible  for.  Because  of  the  diversity  of 
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TABLE  V 

Selected  Software  Entities  and  Attributes 


Entities 

Operating  system 
Operational  support  system 
Environmental  system 
Application  software 

Attributes 

Fro  gram- id  I 

Revision  number  3 

Bevision  cate  ‘ 

Date  comoiled  ] 

Type  of  compiler  ] 

Patch  level  I 

Change  level  < 

License  ! 


Date  released 

Product  number 

Source 

Features 

Document  atior. 

Osage 

Cost 

Maintenance  ac 


Figure  2.3  Logical  Structure  for  Software,  Transactions, 

and  Heport  Fesources. 


controlled  as  carefully  as  ether  major  resources  within  the 
organization.  When  management  has  gained  control  cf  the 
data  resource  by  recording  all  information  about  it,  it  can 
then  begin  to  impose  controls  over  the  availability  of  the 
resource  and  to  develop  standards  for  its  use.  In  this  way 
the  data  resource  can  be  managed  to  the  best  advantage  for 


TABLE  II 

Document/E eport  Attributes 


Name 

Number 

Product  number 
Release  date 
Revision  number 


Source 

Feature 

Description 

Quantity 

Cost 


the  existing  information  system  and  can  be  effectively  rede¬ 
ployed  to  meet  changing  information  requirements.  To  obtain 
this  control  of  the  system  resources,  a  DDS  was  described  as 
being  the  software  tool  that  will  help  to  insure  the  best 
use  cf  the  system  resources. 

In  fche  process  of  gaining  control  of  the  resource,  indi¬ 
viduals  till  lose  the  freedom  to  define  and  use  resources  in 
their  own  way  to  satisfy  their  needs  alone.  In  return  for 
this  loss  of  freedom,  the  user  will  have  access  to  accurate 
information  about  the  definitions  and  usage  of  all  the  data 
contained  in  the  system. 

A  DDS  improves  a  Database  Administrator's  control  over 
the  design  and  the  use  of  the  database.  A  DDS  enables  him 
to  control  and  document  the  formulation,  meaning,  and  usage 
cf  data  structures.  It  enables  him  to  evaluate  existing 
data  redundancy,  provide  accurate  data  definitions  for 
inclusion  in  programs,  and  it  enables  him  to  insure  that 
management's  requirements  for  data  standards  are  obeyed. 
The  most  important  benefits  are  that  the  DBA  will  be  able  to 
assess  gcickly  the  impact  of  any  proposed  change  to  commonly 
used  data  and  to  estimate  the  likely  cost  and  time-scale  of 
any  such  change.  Curing  this  changeover,  the  DBA  can  be 
assured  cf  completeness  (because  the  DDS  will  show  all  the 
programs,  files  and  reports  affected)  and  accuracy  (because 
the  CCS  can  generate  new  coding  to  reflect  the  change) . 


The  systems  designer  will  be  able  to  use  the  DES  as  a 
central  source  of  information.  It  will  allow  him  to  make 
use  of  data  that  is  already  available  and  help  him  tc  avoid 
duplicating  data  definitions,  thereby  preventing  redundancy 
and  inconsistency.  The  DDS  can  generate  data  files  to  be 
used  for  system  testing,  enable  him  to  check  the  contents  of 
data  files  produced  during  systems  testing,  and  provide  the 
designer  with  documentation  of  the  system. 

Application  programming  management  will  be  able  to 
enforce  data  definition  standards  by  insisting  that  all  data 
definition  coding  is  produced  by  the  DDS.  This  will  also 
make  it  easier  to  control  the  implementation  of  design 
changes  that  arise  during  development.  For  the  application 
programmers  themselves,  much  of  the  tedium  of  writing  large 
amounts  cf  coding  will  be  removed.  As  the  DDS  becomes  mere 
involved,  greater  amounts  of  coding  will  be  generated  by  the 
EDS  itself.  Further,  assistance  with  the  generation  of  test 
data  and  the  checking  of  results  by  the  DDS  will  reduce 
application  development  time  and  improve  the  accuracy  of  the 
finished  programs.  Cnee  management  has  used  the  DDS  to 
assess  tie  impact  of  a  proposed  change,  the  task  of  amending 
the  applications  can  proceed  with  increased  confidence.  The 
EDS's  cross-referencing  will  show  the  maintenance  programmer 
precisely  what  programs  will  be  affected  by  a  particular 
change.  As  programs  are  constantly  amended,  the  DDS  can  be 
used  to  record  the  changes  ensuring  programming  management 
control  cf  the  progress  and  completeness  of  the  change.  A 
big  impact  that  the  EDS  has  cn  the  current  system  is  tha* 
before  allowing  the  changed  programs  to  replace  the 
production  versions,  the  DDS  can  be  used  to  generate  test 
data  and  check  results. 

The  operations  department  will  be  impacted  since  it  will 
be  able  to  maintain  the  privacy  of  data  by  reference  to  the 
DDS  tc  check  who  is  allowed  to  use  what  data.  The  DDS  will 


aid  the  department  in  the  creation  of  job  control  lancuag? 
parameters,  control  of  different  versions  of  proem?, 
libraries  and  data  files,  distribution  of  multiple  copies  of 
output,  and  discovering  the  source  of  invalid  data. 

In  summary,  it  becomes  apparent  that  the  introduction  of 
a  DDS  will  have  an  effect  at  many  levels  in  an  organization. 
It  will  create  new  tasks,  but  in  return  will  reduce  the 
effort  required  by  such  activities  as  documentation,  ceding 
cf  programs,  creation  of  test  data  files,  checking  and 
auditing  of  output  files.  The  DDS  will  enable  management  to 
control  data  processing  at  all  levels  and  will  provide  an 
effective  means  of  communicating  data  processing  require¬ 
ments  between  user  departments,  operations  departments,  and 
the  A  DP  department.  System  resources  will  be  recognized  as 
immensely  important  corporate  resources  and  will  be  managed 
and  controlled  accordingly. 


III.  31NEEH  DDL  DATA  CICTIO NARY  AND  DISTRIBUTION  STRATEGIES 


1.  DICTIONARY 

The  need  to  manage  data  resources  requires  systems  iha^. 
identify,  describe,  define,  and  relate  the  basic  unit  of 
information,  the  data  element.  The  TANDEM  Computer  Company 
offers  a  Distributed  Database  Management  System  (DDBMS) 
called  ENCOMPASS  that  handles  this  need.  ENCOMPASS  consists 
cf  standard  software  products:  DATA  DEFINITION  LA  JGUAGE, 

ENFORM  QUERY  LANGUAGE/REPOET  FORMATTER,  TRANSACTION 
MONITORING  FACILITY,  PATHWAY  TRANSACTION  PROCESSING  SYSTEM, 
and  ENABLE  SCREEN  CCECL  GENERATOR  [Ref.  11,12,13].  The 
combination  of  these  software  tools  works  with  the  TANDEM 
NONSTOP  systems  to  provide  a  reliable  and  high  performance 
system  that  is  capable  of  accommodating  peak  workloads, 
hardware  expansion,  database  modifications,  and  application 
growth. 

The  Data  Definition  language  (DDL)  is  a  language 
processor  that  enables  the  user  to  design  and  create  a  data 
dictionary.  This  creation  takes  place  through  a  combination 
cf  statements  and  commands  that  can  be  used  both  interac¬ 
tively  and  in  batch  mode.  By  using  the  DDL  statements,  the 
user  can  define  or  modify  the  structure  of  the  database, 
generate  file  utility  statements  to  create  database  files, 
and  provide  source  language  data  definitions  output  for 
COBOL,  FORTRAN,  and  TA L  ccmpiliers  [Ref.  13].  This 
interaction  is  illustrated  in  figure  3.1. 

The  actual  DDL  looks  like  COBOL  and  provides  two  types 
cf  statements:  DEFINITION  statements  and  RECORD  statements. 
The  DEFINITION  statement  is  a  data  description  independent 
cf  any  record  that  specifies  fields  and  groups.  The  RECORD 
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Figure  3.1  Interaction  of  the  DDL. 


statement  defines  record  structure  and  file  attributes,  and 
can  refer  tc  a  DEFINITION.  When  this  happens  the  groups  and 
fields  of  the  DEFINITION  are  inserted  into  the  RECORD  state¬ 
ment  at  the  point  where  the  DEFINITION  name  is  written. 
Many  RECORD  statements  can  share  the  data  structure  of  the 
same  DEFINITION.  This  application  of  DEFINITION  statements 
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makes  it  easy  tc  standardize  a  data  structure  throughout,  a 
large  database.  This  insures  consistency  of  nomenclature 
and  data  types  among  different  records,  files,  and  programs. 
The  EEL  will  fake  every  DEFINITION  and  RECORD  statement  in 
the  EEL  input  file,  plus  user  comments,  and  catalog  them  tc 
form  a  data  dictionary.  The  data  dictionary  will  he  a 
complete,  centralized  description  of  the  data  structures, 
records,  and  files  that  make  up  the  database. 

This  data  dictionary  will  essentially  be  a  database 
about  the  system  databases.  It  will  provide  a  powerful 
development  tool,  a  central  source  for  data  definitions,  and 
complete  database  documentation.  There  are  two  main 
functions  of  the  cata  dictionary  in  the  realm  of  the 
ENCOMPASS  DDBMS.  First,  the  DDL  data  dictionary  will 
provide  a  database  cf  what  kinds  of  information  are  main¬ 
tained,  such  as  stock  numbers,  document  numbers,  or  routing 
identifiers.  secondly,  it  supports  ENFORM  by  providing 
"mapping"  information  to  describe  the  file  type  and  access 
information  of  the  database.  The  query  processor  cf  ENFCRM 
uses  this  mapping  information  to  determine  the  most 
efficient  way  to  access  the  database. 

A  feature  of  the  data  dictionary,  once  it  has  beer- 
compiled  by  the  DDL,  is  that  it  becomes  a  single  source  for 
all  data  definitions  in  the  database.  This  means  that  every 
program  that  accesses  a  database  can  use  data  declaration 
source  generated  from  the  dictionary.  Therefore,  the  EBA 
can  exercise  control  over  the  structure  of  the  database. 
The  data  dictionary  also  stores  information  in  a  form  acces¬ 
sible  to  the  ENFCRM  COSRY/REECFT  WRITER,  so  users  can  easily 
prepare  ad  hoc  dicticnary  reports.  One  of  the  best  features 
cf  the  TANDEM  data  dictionary  is  that  separate  data  diction¬ 
aries  can  be  stored  cn  separate  disk  volumes  for  different 
databases.  This  feature  allows  concurrent  users  of 

different  dictionaries  to  perform  database  interactions 


without  access  conflicts  that  can  caus°  bortlar.  =  cks 

[Ref.  13]. 

Sines  w a  now  knew  what  the  data  dictionary  within  the 
ENCOMPASS  DDBMS  is  made  up  of,  what  it  provides,  whan  it 
produces,  and  what  its  features  are,  we  must.  new  ask  the 
question  what  can  this  data  dictionary  do  for  SPLICE?  The 
make-up  cf  the  TANDEM  dictionary  will  be  evaluated  according 
to  the  basic  profile  civer.  in  the  earlier  part  cf  this  work. 

B.  DATA  DICTION  AST  CCBPARISONS 

The  following  cctrpariscn  cf  the  below  described  data 
dictionaries  is  intended  to  give  a  rough  evaluation  of  the 
TANDEM  product  relative  to  what  is  currently  available  from 
ether  venders.  In  no  way  are  we  endorsing  a  particular 
product.  The  intent  of  this  limited  survey  is  to  lock  at 
selected  features  offered  by  the  different  software  packages 
and  note  how  the  four  products  compare  without  making  quan¬ 
tifiable  judgements  whether  one  or  another  is  good,  bad, 
superior  cr  inferior.  The  information  provided  in  the 
following  tables  was  derived  from  [Ref.  5,6,11,12,13,14]. 
The  section  begins  with  a  brief  general  description  of  each 
of  the  feur  data  dictionary  packages  considered. 

1  •  Data  Control  System  (DCS) 

The  Data  Control  System  (DCS)  is  a  dictionary  system 
produced  and  developed  by  Cincom  Systems  Inc.  The  system  is 
implemented  as  an  application  program  that  requires  Cincom*s 
DBMS  which  is  called  TOTAL.  DCS  was  previously  referred  to 
as  the  Cinccm  Data  Dictionary. 

2  •  Catamanager 


Datamanager  is  a  free-standing  data  dictionary 
system  that  is  developed  and  marketed  by  MS?  Inc. 


Eatamar.ager  is  the  nucleus  cf  a  family  of  products.  it 
contains  the  facilities  for  creating  and  maintaining 
dictionaries  used  in  a  traditional  file  environment. 
Catamanager  also  has  dictionary  query  facilities  as  well  as 
a  report  generator.  Datamanager  is  not  tied  to  a  particular 
EEMS  ana  is  capable  cf  interfacing  to  IDMS,  AD3AS,  l*S, 
TOTAL  and  SYSTEM  2000. 

3*  EB/EC  Data  D  action  a  ry 

There  are  two  versions  of  the  D3/DC  Data  Dictionary 
which  is  a  product  of  International  Business  Machines  (IBM) 
Corporation.  One  version  is  for  operation  under  OS/VS  and 
the  ether  is  for  operation  under  DOS/VS.  The  EB/DC  Data 
Dictionary  is  a  DECS -app  licatior.  program  with  several 
management  features  which  have  evolved  since  the  product  was 
first  released  in  1974. 

4 .  EDL  Data  Dictionary 

The  Data  Description  Language  (DDL)  Data  Dictionary 
produced  by  TANDEM  Software  Products  Inc.  is  a 
EBNS-application  approach  that  requires  the  TANDEM  DBMS 
called  ENCOMPASS.  The  TANDEM  format  for  dictionary  file 
entries  was  used  in  the  preliminary  DDS  design  proposed  in 
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C.  IN  IIP LAIN AT ION  CF  THE  TEBMS  USED  IN  THE  SURVEY 

SOFTWARE  PACKAGE  NAME:  Nam  e  cr  acronym  by  which  the  D/D  is 
known . 

VENDOR:  Name  of  the  company  that  markets  the  product. 

OPERATIONAL  MODE:  Mcce  in  which  the  D/D  operatss,  batch  or 
online. 

tSE  CF  A  DATABASE  MANAGEMENT  SYSTEM  (DBMS)  :  Note  inferences 
to,  cr  requirements  fcr,  a  DBMS. 

ONLINE  QUERIES?:  Does  the  D/D  have  online  query  capability? 

ONLINE  QUERY  LANGUAGE?:  Does  the  query  language  require 

fixed-fcrm  cr  free-  f  crm  queries? 

SYNONYM?:  Can  a  syncnym  (word  or  abbreviation)  be  used  as  a 

substitute  for  the  data  element  identifier? 

KEYWORD  CAPABILITY?:  Can  an  element  be  identified  as  a 
keywcrd? 

DATA  STRUCTURE:  what  data  structure  is  supported  by  the  D/D, 
network,  hierarchical,  cr  relational? 

VALIDATION:  Is  data  validation  performed  by  the  D/D  cr  by 

seme  ether  means? 

REDU N I ANCY/ INCONSISTENCY  CHECK?:  Is  there  a  specific  feature 
that  identifies  whether  the  data  element  is  redundant  or 
inconsistent? 

DEFI NI II CN/ DESCRIPT I C  N? :  Is  there  a  facility  for  defining 
and/or  describing  a  data  element  in  narrative  form? 

RELATIONSHIPS?:  Is  there  a  capacity  for  specifying  the  rela¬ 
tionship  of  a  data  element  tc  another  data  element  or  to  a 
higher  level  structure? 


CWNEE/USER? :  Is  there  a  facility  for  indicating  authorised 
users  (persons  or  programs)  cr  owners  of  data  elements? 

AD  HOC:  Can  the  user  structure  his  own  reports,  on  an  ad  hoc 
basis? 


D.  ACTIVE  CE  PASSIVE 

The  TANEEM  data  dictionary  function  within  the  SPLICE 
project  would  have  tc  be  categorized  as  an  acti ve/dependent 
DDS.  The  reason  for  this  classification  is  that  the  soft¬ 
ware  package  does  reguire  the  Navy  Supply  System  components 
to  depend  on  the  DES  for  their  data,  and  is  a  software 
package  tha*  functions  mainly  as  a  tool  for  manipulating 
information  about  data  elements  in  a  database.  The  depen¬ 
dent  classification  is  attached  since  this  software  tool  is 
specifically  tailored  to  the  ENCOMPASS  DDBMS.  Ir.  this 
format  the  DDS  will  provide  the  DBMS  with  control  and 
management  of  the  cata  elements  and  in  return  the  DEMS 
resources,  such  as  file  structure  and  access  methods,  will 
be  made  available  to  the  DDS.  Since  the  DDS  is  designed  and 
implemented  within  a  specific  DBMS  environment  its  port¬ 
ability  will  be  restricted  to  installations  having  this 
EBMS. 

E.  SCIT1ARE  INTERFACES 

The  software  interface  provided  in  the  ENCOMPASS  EDEMS 
is  a  static  interface  that  links  the  data  dictionary  with 
ether  systems  indirectly  via  the  extraction  of  a  file  of 
formatted  data.  The  dictionary  contains  the  description  cf 
the  records  within  each  file  and  identifies  primary  and 
alternate  keys.  The  relational  QDERI/REPORT  writing 
language  ENEOHM  uses  these  as  a  template  for  accessing  the 
records.  This  accessed  information  will  provide  "mapping" 
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information  to  describe  the  file  types  and  to  describe  the 
database.  The  query  processor  of  EM  FORM  then  uses  this 
information  to  determine  the  most  efficient  way  to  access 
the  database.  3y  supplying  ‘he  software  package  fc  inter¬ 
face  with  •‘■he  data  dictionary  the  user  has  acquire!  e  iit 
capabilities,  format  options,  and  various  other  functions  to 
make  the  interface  mere  flexible. 

The  drawbacks  in  having  static  interfaces  and  using 
vender-supplied  software  packages  compared  to  the  option  of 
using  dynamic  interfaces  come  in  several  areas.  Changes  tc 
the  data  in  the  data  dictionary  will  not  mean  that  the  data 
cf  the  system  with  which  it  interfaces  will  be  automatically 
updated  and  therefore  data  in  other  systems  can  become 
inconsistent  with  data  in  the  data  dictionary.  Software 
packages  cannot  directly  retrieve  and  update  data  stored  in 
the  data  dictionary  nor  are  all  requests  by  these  packages 
routed  through  the  data  dictionary  so  that  security  and 
validity  checks  of  the  data  dictionary  can  be  applied.  The 
use  of  static  interfaces  is  prevalent  in  the  world  of 
dictionaries  because  cf  their  utility  compatibility,  effi¬ 
ciency,  and  small  overhead.  Since  SPLICE  is  largely 
concerned  with  efficiency  in  performing  transaction¬ 
processing,  this  static  interface  approach  will  be  a  plus 
for  the  project. 

I.  CCBVIRT  FONCTIOBS 

The  convert  functions  offered  by  the  TANDEM  software 
packages  do  not  completely  match  the  definition  given  by 
[Bef.  6].  Convert  functions  are  described  first  as  being 
able  to  scan  source  programs,  database  descriptions,  and 
teleprocessing  environment  descriptions  and  automatically 
produce  maintenance  transactions  that  will  spare  the  DBA 
many  hours  of  manual  effort.  Secondly,  the  convert 


functions  are  offered  to  convert  data  from  both  user-wr  it  tar. 
programs  and  from  a  DBMS  and  its  related  components.  The 
TANDEB  DDL  does  not  perform  the  first  task  but  in  the  area 
of  the  second  function  if  does  operate  very  strongly  as  a 
conversion  facility  for  programming  languages  CC3CL, 
FORTRAN,  and  TAL,  as  well  as  for  the  DDL  compiler  and  the 
report  writer  of  SNFCRM.  The  DDL  compiler,  once  it  has  been 
given  a  list  of  DDL  statements,  can  produce  the  following 
files : 

•  a  data  dictionary 

•  a  file  utility  program  for  file  creation  command  source 

•  a  data  declaration  source  for  COBOL,  FORTRAN,  TAL 

•  a  schema  report  summarizing  each  record's  structure  and 
each  file's  access  keys 

The  INSCRIBE  file  utility  program  (FOP)  commands  will  be 
used  to  create  the  actual  database  files  with  the  specified 
attributes.  The  data  declaration  source  generated  by  the 
DDL  is  available  either  when  the  schema  is  first  compiled  or 
by  accessing  the  data  dictionary  at  any  other  time.  The  DDL 
will  also  provide  edit  checking  for  all  three  source 
outputs.  For  example,  if  the  user  programmer  asks  for  COEOL 
source  output,  the  DDL  checks  to  make  sure  that  the  schema 
includes  nc  COBOL  reserved  words,  and  will  report  what  items 
are  unsuitable  for  the  selected  language.  [Ref.  13]. 

The  question  is  what  does  all  this  mean  for  SPLICE?  By 
gathering  all  of  the  various  database  definitions  and  data 
structure  declaration  functions  into  a  single  language,  the 
DBA  gains  control  over  the  database  design  and  implementa¬ 
tion.  It  also  gives  the  DBA  a  data  dictionary  that  docu¬ 
ments  the  database,  and  can  be  used  in  the  ongoing  process 
cf  database  management.  With  the  data  dictionary  being  able 
tc  regenerate  the  input  source  data  description  from  the 
dictionary  cata,  a  valuable  tool  for  auditing  adherence  to 
software  control  techniques  is  gained.  This  means  the  data 


dictionary  within  the  SPLICE  environment  will  be  able  to 
detect  and  disclose  inconsistencies  in  the  names,  formats. 


and  clauses 


the  record  definitions  used  in  several 


programs  and  the  corresponding  standard  RECORD  definitions 
in  the  data  dictionary  [Ref.  6]. 


G.  ENVIFCNMENT AL  DEPENDENCY 

There  are  three  levels  cf  environmental  dependency 
between  a  data  dictionary  and  a  DBMS:  independent, 

EBMS-application,  and  embedded.  The  environmental  depen¬ 
dency  characteristic  cf  a  data  dictionary  is  determined  by 
the  degree  which  a  data  dictionary  relies  on  the  DBMS  for 
data  management  services  and  the  source  of  data  used  by  the 
DBMS  for  access  to  stored  databases  [Ref.  6]. 

The  data  dictionary  within  the  TANDEM  schema  would  be 
classified  as  having  EBMS-application  characteristics.  This 
allows  random  processing,  on-line  updates,  query  processors, 
and  report  generators  to  be  more  efficient.  The 

DBMS-application  method  used  by  TANDEM  means  that  "ad  hoc" 
queries  and  special  reports  can  be  processed  quickly  and 
that  data  redundancy  can  be  avoided.  It  also  means  that 
dictionary  data  descriptions  can  be  used  directly  by  the 
EBMS  rather  than  having  the  dictionary  generate  DBMS  data 
descriptions.  The  best  advantage  of  the  DBMS-application 
approach  is  that  a  customized  data  dictionary  can  be 
designed  and  implemented  which  meets  the  special  needs  of 
the  SPLICE  information  resource  environment  [Ref.  7].  The 
drawbacks  cf  this  technique  are  that  1)  it  makes  the 

dictionary  less  portable  since  it  is  tied  to  a  specific  DBMS 

and  2)  it  forces  the  user  to  buy  and  support  this  particular 
DBMS  software.  Applying  this  to  the  SPLICE  project,  these 
drawbacks  are  negligible  since  the  project  will  be  using  the 
ENCOMPASS  DBMS  provided  by  TANDEM. 


8.  DISTRIBUTION  COHSIDERAT IONS  FOR  THE  DATA  DICTIONARY 


In  a  distributed  database  environment  there  are  a  number 
cf  options  for  distribution  of  the  data  dictionary.  wirhin 
the  SPLICE  system  every  lan  will  have  a  database  management 
module  for  centralized  control  ever  the  data.  There  are  no 
distribution  of  databases  within  a  lan  [Ref.  4],  The  data 
dictionary  in  the  distributed  environment  itself  becomes  a 
distributed  database.  Databases  may  be  distributed  ever  the 
entire  SPLICE  network  and  the  database  functions  are 
centralized  within  each  lan.  The  goal  here  is  to  satisfy 
control  and  integrity  of  the  data  within  the  network. 

I.  CATA  DISTRIBUTES  STRATEGIES 

The  system  architecture  and  the  network  database  manage¬ 
ment  system  software  determine  the  distribution  strategies 
which  may  be  considered.  There  are  four  types  of  distribu¬ 
tion  strategies  for  consideration. 

t.  Centralized-a  single  copy  of  the  database  is  located 
at  ere  node. 

2.  Partit ioned-a  single  copy  of  the  database  is 
comprised  of  disjoint  subsets  or  partitions  located  at 
various  nodes. 

3.  Replica ted- there  are  multiple  copies  of  the  database 
with  each  node  having  a  complete  copy. 

4.  Hybrid-there  are  multiple  copies  of  subsets  of  the 
database  where  each  node  may  have  as  many  cf  the 
partitions  cf  the  database  as  necessary. 

There  are  different  advantages  and  disadvantages  to  each 
cf  the  feur  distribution  strategies  mentioned.  The  primary 
considerations  for  discussion  are  reliability,  data  storage, 
retrieval  and  update  response  times  and  various  control 


The  centralized  database  concept  has  simplicity  as 


its  major  advantage.  Control  and  update  problems  are  mini¬ 
mized  since  all  the  data  are  located  at  a  single  node. 
Drawbacks  of  this  strategy  include  potential  problems  of 
reliability  or  availability.  If  the  central  node  fails,  the 
system  is  down  completely.  If  there  is  a  high  volume  of 
communications  with  the  central  node,  there  may  be  bottle¬ 
necks  which  slow  down  system  response  time.  Depending  upon 
the  amcunt  cf  secondary  storage,  there  might  also  be  a  limi¬ 
tation  cn  the  possible  size  of  the  database.  These  consid¬ 
erations  are  applicable  to  each  lar.  but  are  not  cf  concern 

for  the  SPLICE  system  as  a  whcle. 

2  •  Partitioned 

Kith  the  partitioned  database  distribution  strategy 
there  is  still  only  cne  copy  of  the  database  however,  it  is 
divided  into  disjoint  subsets  or  partitions  which  are 
assigned  to  particular  nodes  in  the  system.  With  this 
approach,  the  size  of  the  database  is  not  limited  to  the 

amount  of  secondary  storage  at  a  cantral  node  but  is  the  sum 

of  the  total  storage  available  within  all  nodes  of  the 
system.  Retrievals  and  updates  present  less  of  a  problem 
since  they  can  be  directed  to  the  particular  node  where  the 
data  are  located.  Iccess  to  the  local  database  partitions 
lessens  the  possibility  of  bottlenecks  and  may  reduce  commu¬ 
nications  costs.  If  the  requirements  are  for  data  located 
outside  cf  the  local  node,  communications  costs  are  greater 
ar.d  the  delay  in  response  time  also  increases. 

The  benefits  of  the  partitioned  approach  are  highly 
dependent  upon  the  location  of  the  data  required  to  satisfy 
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user  requests.  This  is  also  known  as  locality  of  reference. 
There  is  a  high  degree  of  locality  of  reference  if  the  data 
is  partitioned  such  that  the  data  at  a  particular  node  is 
used  almost  exclusively  by  users  at  that  node.  If  this  is 
not  optimized,  database  availability  is  limited  in  the 
system.  With  the  partitioned  approach,  reliability  of  the 
system  is  improved  ever  the  centralized  approach  because 
failure  at  cne  node  only  causes  a  performance  degradation, 
not  failure  of  the  whole  system.  In  contrast,  the  avail¬ 
ability  of  the  entire  database  is  less  likely  because 
failure  cf  any  node  in  the  system  is  more  probable  than 
failure  cf  the  central  node  in  the  system.  The  partitioned 
strategy  is  most  appropriate  in  a  distributed  environment 
where  there  is  a  limitation  on  secondary  storage  at  the 
central  node,  where  reliability  of  the  system  must  be 
improved,  cr  where  there  is  a  possibility  for  operating 
efficiencies  to  to  be  gained.  A  high  degree  cf  locality  cf 
reference  in  database  access  patterns  implies  that  operating 
efficiencies  can  be  gained  through  partitioning  of  the  data¬ 
base.  Within  the  SPLICE  environment,  determining  the 
optimal  partitioning  strategy  to  ensure  system  efficiency 
poses  a  difficult  problem. 

3 .  Replicated 

In  the  replicated  distribution  strategy  each  node 
within  the  system  is  allocated  a  complete  copy  of  the  data¬ 
base.  The  network  database  management  system  is  responsible 
for  coordinating  the  multiple  copies  of  the  database  but 
there  is  not  a  problem  of  determining  which  nodes  have  which 
part  of  the  database  as  there  is  with  the  partitioned 
approach.  The  replicated  approach  is  most  advantageous  in 
the  areas  of  reliability,  availability  and  retrieval 
response  time.  As  with  the  centralized  approach,  the  size 
cf  the  database  may  be  limited  by  the  size  of  the  secondary 


storage  at  each  node.  Faster  response  times  fcr  user 
requests  are  possible  because  there  is  no  need  to  gc  oursics 
of  a  particular  node  for  database  access.  This  also  implies 
that  ccmmunica ticn  costs  would  be  cheaper  as  most  network 
communication  would  be  localized.  Wizh  the  replicated 
approach,  reliability  is  high  in  terras  of  data  availability 
and  if  a  particular  node  fails,  there  is  no  lost  portion  of 
the  database.  Another  copy  of  the  complete  database  could 
be  generated  from  a  neighboring  node.  This  simplicity  of 
backup  and  recovery  operations  is  another  of  the  advantages 
of  the  replicated  approach.  If  a  node  within  the  system 
fails,  there  must  be  controls  in  the  updates  that  may  be 
performed  tc  maintain  the  integrity  of  the  database.  This 
is  tc  say  that  independent  updates  of  separate  nodes  must 
not  be  allowed  or  there  will  be  likely  data  inconsistencies, 
locking  mechanisms  must  be  employed  to  ensure  data 
integrity. 

The  replicated  distribution  strategy  is  most  appro¬ 
priate  where  the  database  is  not  too  large,  reliability  is 
critical  to  the  system  and  inefficiencies  of  updates  can  be 
accepted.  This  implies  a  retrieval-intensive  database 
system.  The  amount  of  overhead  for  communications  and 
processors  needed  because  of  synchronization  and  control 
complexities  in  a  replicated  system  is  dependent  upon  the 
level  cf  consistency  required.  Within  the  SPLICE  system  the 
data  dictionary  should  be  fairly  static  once  implemented. 
With  only  limited  update  requirements,  the  replicated 
strategy  for  the  SPLICE  data  dictionary  is  the  recommended 
approach. 

4 .  Hybrid 

The  hybrid  distribution  strategy  is  a  combination  of 
the  partitioned  approach  and  the  replicated  approach  tc  data 
distribution.  The  database  is  partitioned  into  disjoint 
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subsets  however,  in  this  strategy  there  may  be  several 
replicated  partitions.  Each  part  of  the  database  can  be 
replicated  any  number  of  times  and  each  node  may  have  that 
portion  of  the  entire  database  which  optimizes  performance 
at  that  ncde.  This  strategy,  if  properly  implemented  with  a 
high  degree  of  locality  of  reference,  should  limit  the  need 
for  node  tc  node  communications  thus  reducing  costs  and 
potential  communications  bottlenecks.  The  hybrid  strategy 
improves  the  reliability  of  the  system  over  the  strictly 
partitioned  approach.  The  key  advantage  of  the  hybrid 
approach  is  flexibility  in  how  the  data  are  stored.  Nodes 
with  limited  secondary  storage  may  tailor  their  partition 
for  functional  optimization  whereas  nodes  which  demand  a 
high  degree  of  reliability  and  faster  response  times  may 
duplicate  a  larger  pcrtion  of  the  database  tc  satisfy  their 
needs. 

The  flexibility  provided  by  the  hybrid  approach  is 
achieved  at  the  cost  of  system  software  complexity.  The 
network  EBMS  must  not  only  keep  track  of  where  data  exist  in 
the  network  but  it  must  also  be  capable  of  synchronization 
cf  the  data  updates.  Query  optimization  and  query 
processing  are  nontrivial  tasks  in  the  hybrid  environment. 
Because  cf  the  software  complexity  necessary  to  implement 
the  hybrid  strategy,  the  question  is  whether  the  flexibility 
to  be  gained  by  this  approach  is  worth  the  tradeoff.  A 
likely  candidate  for  the  hybrid  approach  might  be  a  system 
with  a  large  database  that  has  only  a  few  nodes  capable  of 
handling  a  replicated  approach  and  where  high  reliability  is 
essential  in  the  ncdes  which  have  the  secondary  storage 
capacity  to  accommodate  a  large  portion  of  the  database. 


J.  J IAMELE  OP  TANDEM  DATA  DICTIONARY  FILES 


Th€  following  schema  consists  of  20  objects  (18  defini¬ 
tions  and  two  records) .  These  objects  will  be  used  to 
construct  an  example  for  the  SPLICE  dictionary  and  its 
related  files.  [Ref.  13]  was  used  as  a  format  guide  and  for 
explainaticr.  of  the  files  which  follow. 


?COMM  ENTS 


*  Document  Number  uniquely  identifies  reauestor,  date  and 

*  local  serial  number. 

EEF  EOCNOK  HEADING  "Document  Number" 

02  Service  PIC  £. 

02  Unit  Ic  Code  PIC  $  (5) . 

02  Julian  date  PIC  9  (4)  . 

02  Serial  num  PIC  9(4). 


*  National  Stock  Numbers  are  classified  by  grouDs 

*  catgorizing  items  by  individual  characteristics,  and 

*  uniquely  indentified  within  the  Federal  Supply  System. 

DEF  NSN  HEADING  "Nat'l  Stock  Number". 

02  Fed  Sup  Class  PIC  9(4). 

02  NUN  TYPE  *. 


*  Document  Identifier  which  indicates  the  purpose  and  use  of 

*  the  document  (i.e.  ,  requisition,  referral,  follow-up, 

*  status,  etc.) .  The  Eocument  Identifier  is  a  mandatory 

*  entry  cr.  each  milstrip  document. 

EEF  EOCID  PIC  AXX  HEADING  "DOCUMENT  IDENTIFIER" 


*  Routing  identifier  is  used  to  represent  the  address  of  the 

*  intended  recipient  cf  the  document;  to  denote  the  actual 

*  consignor  of  material;  or  to  identify  the  supply  activity 

*  originating  the  action. 

DEF  ROOTID  EIC  AX9  HEADING  "ROOTING  IDENTIFIER" 


*  Forecast  level  of  expected  demands  for  next  quarter 

*  according  to  demand  for  the  past  six  months. 

DEF  DMDFOEECAST  EIC  9(4)  HEADING  "DEMAND/FORECAST" 


*  Minium  items  on  hand  to  meet  war  reserve  requirements. 
DEF  RESERVATION  EIC  9999  HEADING  "RESERVATION" 


*  A  stocking  level  that  is  computed  by  adding  demand  during 

*  lead  time  plus  safety  stock. 


DEF 


HECHDERPOINT  EIC  9(4)  HEADING  "REORDER/POINT" 


*  A  managerial  technique  used  to  protect  aqainst  a  stockout. 

*  An  crder  can  be  computed  and  placed  so  rhat  the  delivery 

*  will  arrive  when  a  certain  level  of  inventory  is  still 

*  there. 

DEF  SAFETY  LEVEL  EIC  9(4)  HEADING  " SAFETY/LEVEL'* 


*  Number  of  units  that  have  outstanding  requisitions  against 

*  them. 

DEF  BACKORDER  EIC  9(5)  HEADING  "3ACKOFDER" 


*  This  gives  the  general  category  of  a  part,  i.s.,  resistor. 
DEF  PART  NAME  EIC  A(10)  HEADING  "PART/NAMS" 


*  The  Media  Status  Cede  indicates  the  recioient  of  status 

*  and  tte  means  cf  transmission. 

DEF  MEDIA  STATUS  EIC  X  HEADING  "MEDIA/STATUS" 


*  This  two  digit  alp ba/numeric  figure  identifies  who  has 

*  inventory  and  technical  responsibility  for  an  item. 

DEF  ACCOONT/COG  EIC  XA  HEADING  "ACCT/COG" 


*  Priority  combines  tte  assigned  force/activity  designator 

*  and  the  appropriate  urgency  of  need  designator  and  enables 

*  the  raquisitioner  to  determine  the  appropriate  priority 

*  code. 

EEF  FRI  EIC  99  HEADING  "PRIORITY  CODE" 


*  Expected  means  of  transporting  items,  and  received  in 

*  shimpment  status  documents. 

EEF  MODE  PIC  X  HEADING  "MODE  OF  SHIPMENT" 


*  National  Item  Identification  Code  uniquely  identifies  a 

*  line  item  within  the  Federal  Supply  System. 

EEF  NUN  PIC  9(9)  HEADING  "NUN" 


*  A  description  of  the  types  of  units  under  which  material 

*  is  issued. 

DEF  UNIT  CF  ISSUE  EIC  AA  HEADING  "UI" 


*  Cost  of  an  item  per  unit  cf  issue 

EEF  UNIT  PRICE  EIC  9(6)VS9  HEADING  "UP" 


*  Number  of  items  of  the  object  per  unit  of  issue  that  are 

*  physically  located  at  that  particular  stock  point. 

DEF  QTY  ON  HAND  EIC  99S99  HEADING  "ON/HAND" 


string  s. 


r 


and  VALUE 


HEADINGS  strings 


DISPLAY  strings. 


literals  are  all  text  items.  The  previous  schema  has 
75  test  items  and  therefore  the  text  counr  stands  at 
figure  3.2,  shows  how  this  file  would  look. 


75. 


NEXT 

OBJECT 

20 


NEXT 

TEXT-ID 

75 


DICT  ION  ARY 
VERSION 


Figure  3.2  Dictionary  Definition  File. 

The  Object  Definition  File  (ODF)  is  a  key-sequenced  file 
that  contains  one  record  for  every  object  entered  into  the 
dictionary.  Figure  3.3  shows  this  file  according  tc  the 
schema  previously  given.  The  ODF  file  uses  the  object 
number  from  the  DDF  to  identify  the  object.  The  object 
number  is  followed  by  object  name  with  an  object  type 
(either  ID  the  symbol  for  definitions  or  RD  the  symbol  for 
records) .  The  COMMENTS-  TEXT-  ID  field  is  used  for 
dictionary  comments  associated  with  the  entire  RECORDS 
(comment  lines  that  immediately  precede  a  RECORD  statement 
in  the  DDL  source  schema).  The  values  are  assigned  by  the 
CDF. 

The  Object  Build  list  (OBL)  is  a  key-sequenced  file  that 
contains  one  record  for  each  element  of  each  object  ir.  the 
DDL  schema.  The  records  are  identified  by  the  object  number 
that  they  received  in  the  ODF.  An  element  number  is 
assigned  that  identifies  each  element  within  an  object.  A 
complete  description  cf  an  element  can  be  obtained  from  the 
CBL  record  (i.e.,  the  elements  name,  data  type,  size,  offset 
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Figure  3.3  Object  Definition  File. 

within  the  object,  and  text-id  number).  Figure  3.4  shews 
hew  the  OBI  element  records  are  linked  to  the  ODF  for  a 
typical  object ,  the  DEMAND  HISTORY  FILE  record. 
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The  Cbject  Text  File  (OTF)  is  a  key-sequenced  file  that 
contains  one  record  for  each  line  of  input  of  a  dictionary 
COMMENT,  HEADING  string,  DISPLAY  string,  PICTURE  string,  ana 
VALUE  literal  in  the  DDL  schema.  The  OBL  links  to  the  CT? 
cn  TEST-ID  fields,  cns  to  many.  Figure  3.5  shews  a  partial 
layout  from  the  previous  schema. 
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Figure  3.5  Object  Text  File. 

The  Record  Defirition  File  (RDF)  is  key-sequenced  and 
contains  one  record  for  each  RECORD  in  the  DDL  schema.  The 
cbject  number  assigned  to  the  RECORD  through  the  ODF 
uniquely  identifies  each  record.  The  RDF  record  also 
contains  a  DEF- NUMBER  and  if  the  record  has  been  defined 
with  a  DEFINITION  IS  clause  then  DEF-NUMBER  will  hold  the 
cbject  number  of  the  DEFINITION.  If  this  is  not  true,  then 
the  DEF-NUMBER  assumes  the  cbject  number  of  the  RECORD 
itself.  The  file  type  and  file  duration  fields  give  details 
to  the  structure  of  the  RECORD  (i.e.,  unstructured,  rela¬ 
tive,  entry-sequenced,  key  sequenced)  and  the  permanence  of 
the  RECORD.  The  RDF  links  back  to  the  ODF  one  to  one  plus 
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the  REF  links  to  the  03L  one  tc  many.  Figure  3.6 
example  of  this  file. 
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Figure  3.6  Record  Definition  File. 


The  Key  Definition  File  (KDF) ,  is  also  key-sequenced  and 
contains  one  record  for  each  primary  key  and  each  alternate 
key  declared  for  each  record  in  the  schema.  The  identifica¬ 
tion  cf  the  KDF  record  comes  from  the  object  number  that  has 
teen  assigned  by  the  03L.  The  RDF  links  to  the  KDF  on 
RECORD- NUMEER,  one  to  many  and  KDF  links  to  the  OBI  by 
DEF- NUMEER/ DEF  ELEMENT  One  to  cne.  This  layout  is  shown  in 
figure  3.7 
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Figure  3.7  Key  Definition  File. 


Kith  the  dictionary  files  described  and  examples 
provided,  it  is  important  tc  realize  that  these  files  can  b<- 
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linked  through  primary  and  alternate  keys.  This  capability 
provides  the  DBA  with  a  complete  picture  of  the  data 
elements  within  the  supply  system.  Figure  3.8  shows  on*  set 
of  possible  linkages  between  the  dictionary  files.  Ev  no 
means  does  •‘■his  diagram  show  all  possible  links  between  the 


IV.  DESIGN  OP  A  SPXJCS  DIBECTOHI  BASED  UPON  TANDEM  D22S 


A.  D1BECTOBT 

The  software  package  that  formulates  the  data  dictionary 
does  a  good  job  of  describing  each  data  element  (i.e.,  +ells 
what  it  is)  but  it  dees  little  to  tell  a  user  the  location 
cf  each  data  element  (i.e.,  where  it  is)  within  the  SPLICE 
system.  Without  the  capability  of  retrieving  this  directory 
information,  the  present  layout  of  the  data  dictionary 
cannct  satisfy  the  following  queries: 

•  what  locations  in  the  network  stock  item 
59C5-00-255-3699,  resistor,  fixed,  composition? 

•  Who  is  the  inventory  manager  who  holds  technical 
responsibility  and  what  is  the  latest  status  for  a 
particular  electronic  tube? 

•  Who  is  the  manufacturer  of  an  item  and  where  is  this 
manufacturer  located? 

Even  though  all  of  these  questions  can  be  answered  in  a 
matter  cf  time  by  any  of  the  UADPS-SPs  manually,  they  cannct 
he  answered  on-line  by  use  of  the  proposed  SPLICE  system, 
the  ENCOMPASS  DBMS,  or  the  data  dictionary.  The  development 
cf  a  "customized"  data  directory,  to  be  defined  using  the 
EDL  offered  by  the  TANDEM  DBMS,  is  suggested.  Basically 
this  wculd  be  the  same  as  defining  a  database  through  the 
capabilities  of  the  DDL.  Once  this  directory  has  been 
created  and  is  in  use,  the  data  dictionary  itself  can  be 
queried  fcv  ENFOHM  tc  obtain  information  about  the  directo¬ 
ry's  data  structure  and  location.  Creation  of  a  simple 
directory  is  the  foundation  of  the  concept.  As  technology 
improves  and  the  directory  becomes  a  more  useful  software 
tool,  its  capabilities  no  doubt  will  be  expanded. 
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The  directory  which  is  to  be  defined  is  ore  which 
contains  the  necessary  information  that  will  answer  th=  to? 
ten  cr  fifteen  questions  at  a  local  stock  point.  These 
questions  are  most  likely  to  be  about  line  items  (repaira- 
bles  cr  consumables),  their  location  within  rhe  system, 
quantity  on  hand,  manufacturer,  and  who  has  control  ever  the 
items  within  the  Navy  Supply  System.  To  answer  these  ques¬ 
tions  the  directory  must  store  information  about  the  basic 
aspects  cf  line  items  within  the  system.  Line  items  will 
range  from  repairables  for  ships,  airplanes,  and  machinery 
to  consumables  such  as  screws,  bolts,  and  clothing. 
Therefore  it  is  assumed  that  this  directory  will  contain 
information  about  inventories  and  locations. 

The  TANEEM  DBMS  uses  a  relational  approach  in  defining  a 
database  and  that  fits  our  needs  well.  The  relational 
approach  to  data  is  based  on  the  realization  that  files  that 
obey  certain  constraints  may  be  considered  as  mathematical 
relations,  and  hence  that  elementary  theory  about  mathemat¬ 
ical  relations  may  be  brought  to  bear  on  various  practical 
problems  of  dealing  with  data  in  such  files  [Ref.  15]. 

B.  DATA  ELEMENTS  FOB  THE  DIRECTOR? 

The  files  within  the  directory  must  store  information  on 
several  aspects  of  the  line  items:  stock  item  identifica¬ 
tion,  location  of  manufacturer,  and  stock  point  location. 
The  information  describing  each  of  these  areas  of  the  supply 
system  is  shown  in  table  IX,  table  X,  and  table  XI. 

C.  FILE  STRUCTURES 

As  mentioned  earlier,  all  the  files  in  the  directory  are 
defined  as  relational  files  that  are  uniquely  defined  by  the 
value  stcred  in  its  primary  key  field.  with  a  primary  key 
value  assigned,  ENSCBIBE,  the  database  manager  of  TANDEM, 
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TABLE  IX  f 

Stock  Ite*  Identification  1 

• 

NATIONAL  STOCK  NUMBER 

* 

ACCOUNT/COGNISANCE 

• 

MANUFACTURER  CODE  SOMBER 

* 

NOUN  NAME 

• 

FART  NUMEER 

* 

UNIT  OF  ISSUE 

SPECIAL  MATE FIAL  ID  CODE 

# 

SITS  NAME 

« 

LOCATIONS 

* 

ITEM  MANAGER 

• 

TECHNICAL  RESPONSIBILITY 

♦ 

PRICE 

_ _ _  _ i 

can  randomly  position  itself  anywhere  within  these  files  for 
a  read,  write,  or  update  operation.  Another  step  in 
defining  each  file  is  to  evaluate  what  data  elements  ether 
than  the  primary  key  will  frequently  be  used  as  access  paths 
into  the  files.  If  these  data  elements  are  assigned  as 
alternative  key  fields,  then  ENSCRI3E  can  selectively  read 


TABLE  XI 

Stock  Point  location  Fils 


•  NATIONAL  STOCK  NUMBER 

•  CHASTITY  OS  HAND 

•  LOCATION 

•  REORDER  POINT 

•  OUTSTANDING  REQUISITIONS 

•  SUPPLY  CONDITION  CODE 

•  PURPOSE  CODES 

•  HOLD  CODE 


*  SITE  NAME 

*  UNIT  OF  ISSUE 

*  PRICE 

*  BACKORDER 

*  SAFETY  LEVEL 

*  REPAIR  STATUS 

*  MODE  OF  SHIPMENT 

*  PERSONNEL  DIRECTORY 


L. 


J 


records  from  the  files  or  the  basis  cf  either  full  or 
partial  alternative  key  values.  These  keys  are  not  required 
to  be  unique  [Ref.  13].  I 

1 •  Stock  Item  Identification 

The  Stock  Item  Identification  information  is  broken 
into  three  files:  line  items,  stock  location,  and  material 

contrcl.  The  data  elements  within  these  files  describe  what 
line  items  are  stocked  in  the  Navy  Supply  System,  where 
these  items  are  stocked,  and  who  has  been  assigned  the 
overall  responsibility  of  each  individual  line  item.  Figure 
h. 1  shews  the  information  in  each  file,  primary  and 
alternative  keys  and  the  linkage  between  the  files. 

2.  File 

The  manufacturer  file  uses  three  files  identified 
as:  manufacturer,  order,  and  order  description.  These  files 
hold  information  pertaining  to  the  manufacturer 


*  .  *  .  •  .  » 


jv  ,v  s  ^  .>  *>  «> 


LINE  ITEMS 


MATERIAL  CONTROL 


*•  NATIONAL  STOCXNUNBER 
•  PART  NUMBER 
NOUN  NAME 

SPECIAL  MATERIAL  10  COOE 
MANUFACTURER  NUMBER 
UNIT  OF  ISSUE 
PRICE 


*  ITEM  MANAGER 
LOCATION 

TECHNICAL  RESPONSIBILITY 

location 

•*  ACCOUNT/COGNIZANCE 


STOCK  LOCATION 


•*  PRIMKEY 

-ACCOUNT/COGNIZANCE 
-NATIONAL  stock  nunicr 
•  SITE  NAtC 
LOCATION 
-AOORCSS 
-cm 
-STATE 


**  PRIMARY  KEY 
*  ALTERNATE  KEY 


ONE  TO  ONE  LINK 
MANY  TO  ONE  LINK 


figure  4.1  stock  itea  Identification. 


identification  and  location,  orders  outstanding  with  that 
manuf actcrer,  and  when  these  orders  are  to  be  delivered. 
Ihev  will  also  show  what  part  these  orders  are  for,  how  much 
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they  cost,  and  with  whom  this  order  was  placed.  Figure  u.2 
represents  '■his  structure  with  the  keys  identified  plus  the 
relationships  between  these  files. 
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3.  Stock  £omt  location  File 


The  information  needed  in  this  file  is  divided  into 
three  files  that  are  labelled  inventory  detail,  site  direc¬ 
tory,  and  status.  These  files  would  give  the  requestor 
detailed  information  cn  each  stock  item  that  is  carried  by 
this  particular  activity,  a  directory  of  the  personnel 
within  the  activity  stock  point,  and  the  status  of  any  docu¬ 
ments  of  the  requestor  that  might  have  been  passed  to  this 
activity.  Figure  4.3  shows  these  files  and  how  they  relate 
to  one  another. 

B.  DIRECTORY  DISTRIEOTIOH 

The  question  of  which  distribution  configuration  to  use 
in  locating  this  directory  within  the  SPLICE  project  can 
best  be  handled  by  deciding  the  characteristics  of  the 
data/infcrmation  to  be  controlled  by  the  directory.  The 
data  within  the  defined  SPLICE  directory  car.  be  classified 
as  either  static  or  dynamic  when  considering  updates 
[Ref.  16  ].  The  static  classification  does  not  mean  the  data 
cannot  chance  but  changes  cccur  infrequently  and  therefore 
this  type  of  data  presents  few  problems  in  controlling  data 
integrity.  On  the  ether  hand,  dynamic  data,  that  is  data 
with  a  lew  to  high  update  rate,  presents  a  challenge  when 
trying  tc  maintain  data  integrity. 

E.  STATIC  OR  DY1&HIC 

The  SPLICE  directory  that  has  been  defined  consists  of  a 
combination  of  data  that  has  static/dynamic  updates.  Within 
this  area  cf  concern  are  several  classes  of  data.  The 
classes  are  divided  according  to  the  complexity  of  the 
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Figure  4.3  Stock  Point  Location  File. 


updates.  These  classes  of  updates  range  from  CLASS  0  (i.e., 
data  which  does  not  change)  tc  CLASS  4  (i.e.,  data  for  which 
an  update  may  trigger  an  action  in  a  different  machine) 

[Ref.  16], 


The  data  that  would  be  located  in  the  stock  item  identi¬ 
fication  files  meets  the  definition  of  static  updates  and 
contains  CLASS  1  data.  Updates  to  the  data  in  this  portion 
of  the  directory  would  be  made  by  additions,  deletions,  or 
replacement  and  would  most  likely  be  made  via  batch  mode. 
Simple  updates  of  data  such  as  these,  if  performed  twice, 
cause  very  little  harm.  The  data  in  the  manufacturer  files 
would  be  grouped  in  the  dynamic  category  with  updates  being 
fairly  lew  and  ccntairing  CLASS  2  data.  This  class  of  data 
is  a  little  more  sensitive  to  updates  and  any  updates 
applied  twice  could  cause  the  loss  of  data  integrity. 
Update  transactions  ir  this  area  would  involve  cancellations 
cf  orders  or  possible  changes  in  the  quantity  ordered.  If 
repeated,  this  would  mean  the  loss  of  data  integrity.  If 
the  update  is  only  delayed  but  not  lost,  there  would  be  no 
harm.  A  simple  control  technique  of  assigning  a  serial 
number  to  each  update  transaction  would  ensure  that  no 
transaction  is  lost  or  double-processed.  The  stcck  point 
location  data  is  alsc  dynamic  in  nature  but  with  a  high 
update  rate.  The  data  is  categorized  as  CLASS  3  meaning 
that  the  data  is  very  sensitive  to  time-critical  updates. 
Updates  in  this  area,  if  reapplied  at  a  different  time,  may 
not  have  the  same  effect.  For  example,  if  the  quantity-on- 
hand  field  shows  100  EA  in  stcck  for  a  particular  screw  but 
the  recent  issue  of  50  EA  is  not  reflected  before  a  request 
for  75  EA  ccmes  in  from  another  activity,  the  requester  is 
going  to  stop  looking  since  he  thinks  his  demand  can  be 
satisfied  by  this  activity.  In  actuality  he  needs  to  find 
an  activity  that  has  25  EA  more.  A  control  technique  that 
can  be  applied  is  tke  use  cf  timestamps  to  ensure  that 
transactions  are  net  processed  in  an  invalid  sequence. 
Serial  numbers  may  be  needed  as  well  as  timestamps  to 
prevent  loss  or  double  processing  of  transactions  on 
recovery  [Ref.  17]. 
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The  ccr.cept  of  system  architecture  and  the  nstvcr< 
database  management  system  software  deciding  the  distribu¬ 
tion  strategies  for  dictionaries  also  holds  true  for  the 
distribution  of  directories.  The  four  types  of  distribution 
strategies  which  where  discussed  in  Chapter  III,  along  with 
their  advantages  and  disadvantages,  similarly  apply  to  th» 
directory  portion  of  the  DDS.  Of  the  four  strategies 
mentioned,  it  is  suggested  that  the  hybrid  solution  be  given 
the  most  attention  though  its  inherent  complexity  is 
acknowledged. 

I.  BIBR3D  SOLUTION 

A  hybrid  solution  is  one  where  multiple  copies  of  the 
subsets  of  the  directory  are  replicated  within  the  network 
and  each  node  may  have  a  partitioned  fraction  of  the 
directory  [Ref.  16]. 

Sith  this  description  in  mind  it  is  suggested  that  the 
stock  identification  files  and  the  manuf act ureer  files  be 
replicated  at  the  inventory  control  points  located  at  ASO 
EHIL  AEEPEIA  and  SPCC  MECH ANISBORG  plus  NSC  NORFOLK,  NSC 
CAKLANE,  and  NSD  SDSIC  BAY.  The  stock  point  location  files 
would  then  he  be  partitioned  at  each  UADPS-SP  activity  that 
held  line  items  for  issue.  The  justification  behind  this 
type  of  distribution  falls  back  to  the  characterist ics  of 
the  updates  toward  each  file,  and  the  differences  in  data  at 
each  site,  since  the  first  two  files  will  experience  static 
or  low  volume  updates  and  therefore  is  less  likely  to  have 
high  vclume  of  communication,  the  problems  concerning  reli¬ 
ability,  response  tine  fcr  both  retrievals  and  updates,  and 
data  integrity  are  net  as  hard  to  control  or  manage.  In  the 
case  of  the  stock  pcint  location  files  there  is  very  high 
updating  and  the  make-up  of  line  items  carrried  at  each  site 
is  very  diversified.  Since  the  data  that  pertains  to  each 
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dispersed  activity  is  centralized  at  that  location  the  prob¬ 
lems  cf  data  integrity,  communication  cost,  and 
synchronization  cost  should  be  lowered. 

This  solution  takes  advantage  of  natural  patterns  of 
usage  and  transaction  processing  and  is  structured  around 
those  patterns.  For  example,  most  of  the  customers  at  a 
local  site  will  normally  operate  through  their  local  supply 
department  to  meet  their  needs.  These  transactions  require 
only  simple  transaction  processing.  This  makes  it  feasible 
to  keep  the  stock  pcint  location  files  at  each  local  site. 
It  is  also  true  that  sometimes  the  customer  cannot  be  satis¬ 
fied  by  the  local  site  and  therefore  has  the  need  to  gc  off 
station  which  will  require  a  complex  transaction  tc  be 
performed.  When  this  happens  the  requestor  is  looking  for  a 
central  site  that  can  give  directions  to  a  site  that  can 
handle  the  requirement.  The  directions  that  are  being 
sought  will  be  handled  by  the  replicated  directory  at 
whichever  cf  the  five  sites  is  closest. 

This  information  is  obtained  by  a  user  through  the  use 
of  a  "LINK"  command  statement  that  is  offered  by  ENFCRM ,  the 
guery  specification  language.  This  statement  offers  a 
convenient  means  of  connecting  associated  data  independent 
cf  its  location  and  without  altering  physical  files.  Dsing 
a  key  field,  LINK  identifies  the  relationship  between  two  or 
more  file  descriptions  from  the  directory.  Once  this 
process  has  taken  place  the  relationships  are  combined  so 
that  they  appear  tc  the  user  as  a  single  logical  file 
(Ref.  12].  The  three  groups  of  files  that  have  been  previ¬ 
ously  defined  are  shown  together  in  figure  4.4.  This  figure 
shows  seme  of  the  possible  links  between  the  various 
distributed  files. 


The  Navy  Supply  System  is  a  good  example  of  a  complex 
distributed  information  system.  To  solve  a  problem  win  hit 
this  system,  the  patterns  of  usage  ar. d  methods  of  trans¬ 
action  processing  must  be  followed  and  used  to  answer  the 
guesticns  of  where,  how  much,  and  what  data  to  put  at  each 
node.  The  hybrid  solution  dees  this,  thus  facilitating  the 
design  and  implementation  of  a  directory. 


G.  BENEFITS  OF  A  SPIICE  DIBECTORY 

The  SFIICS  directory  as  defined  above  would  put  thou¬ 
sands  of  useful  records  at  a  wide  variety  of  users’  finger¬ 
tips.  Through  this  cn  line  directory,  a  user  could  access 
the  location  of  available  stock,  manufacturer's  action  on 
criers,  and  even  the  status  of  their  requisitions  at 
different  sites.  Valuable  time  would  no  longer  be  wasted 
looking  up  and  writing  down  line  items  carried  by  a  site, 
manufacturer's  name  and  address,  or  stock  site  personnel 
contacts  every  time  they  were  needed.  The  SPLICE  directory 
would  provide  this  information  to  the  requestor.  The  direc¬ 
tory  records  would  be  available  through  any  of  the  sixty-two 
proposed  sites,  would  be  current,  and  updatable.  Cnee  the 
directory  information  has  been  retrieved,  a  user  can  revise, 
create,  or  delete  a  report /record  of  the  selected  informa¬ 
tion  that  is  needed  by  using  the  features  of  enform.  At  the 
same  time,  the  directory  would  be  secure  by  only  allowing 
alterations  made  by  authorized  personnel. 

It  is  easy  to  see  that  the  directory  could  provide  many 
benefits  to  a  wide  variety  of  users.  The  immediate  result 
cf  providing  a  directory  would  be  that  the  directory  would 
take  the  place  of  numerous  manual  searches,  saving  time  and 


v.  conclusions 


1.  IDENTIF 2 CAT ICS  OF  SEED 

Considering  the  diversity  of  the  application  programs 
that  will  be  tied  to  UADES-SP  under  the  SPLICE  project, 
there  is  a  critical  reed  for  a  tool  to  manage  the  preponder¬ 
ance  cf  system  resources.  A  DCS  will  offer  the  capabilities 
needed  to  control  and  manage  the  data  resources  in  the 
intricate  and  highly  complex  distributed  SPLICE  network 
system.  Helative  tc  this,  a  key  aspect  of  a  DDS  is  that  it 
provides  resource  independence. 

B.  BENEFITS 

There  are  many  benefits  that  a  SPLICE  DDS  can  provide. 
The  ECS  serves  DBAs,  system  analysts,  software  designers  and 
programmers  by  requiring  definitions  of  system  data 
elements,  files,  programs  and  reports.  conversion  to 
unifcrm  resource  description  standards  allows  systems  within 
the  SPLICE  network  tc  interface  easier  and  more  freely.  By 
establishing  standards  of  data  definitions  and  descriptions 
for  applications  programs  throughout  the  SPLICE  system,  the 
DDS  serves  as  the  focal  point  for  future  analysis  and 
design.  Using  a  DDS,  data  can  be  managed  to  the  best  advan¬ 
tage  fcr  the  existing  information  system  and  can  be  effec¬ 
tively  redeployed  to  meet  changing  information  requirements. 
The  DCS  can  be  used  tc  generate  test  data  and  check  results 
before  allowing  chanced  programs  to  replace  the  production 
versions. 


C.  STNOESIS 


This  thesis  reviewed  the  current  status  of  the  SPLICE 
CDS  and  proposed  a  TANDEM  DDS  for  SPLICE.  Basic  concerns 
and  considerations  in  evaluating  a  DDS  were  discusssc  ani 
these  fundamental  principles  were  applied  to  the  TANDEM  Data 
Dicticnary  and  a  preliminary  Directory  design  based  upon  the 
TANDEM  CEMS.  A  brief  comparison  was  made  of  the  TANDEM  Data 
Dicticnary  and  other  commercial  products. 

The  TANDEM  Data  Dictionary  is  essentially  a  data  element 
dicticnary.  It  is  a  DBMS -application  approach  to  a  DDS. 
The  product  does  not  have  directory  capabilities  at  this 
time.  The  dictionary  is  an  active/dependent  system  which 
would  require  that  SPLICE  system  components  depend  upon  the 
dicticnary  for  their  data.  Its  usefulness,  in  its  present 
form,  would  primarily  be  as  a  tool  for  manipulating  informa¬ 
tion  abcut  data  elements  in  a  database.  The  TANDEM 
dictionary  operates  effectively  as  a  conversion  facility  for 
three  different  programming  languages  as  well  as  for  the  DDL 
compiler.  By  placing  the  data  definitions  and  data  struc¬ 
tures  in  a  single  language,  the  DBA  gains  control  ever  th= 
database  design  and  implementation.  Considering  the  volume 
of  data  in  SPLICE  and  its  ccmplexity,  this  would  be  an 
advantageous  feature. 

D.  FINAL  COMMENT 


i 


A  DDS  is  a  powerful  information  management  tool  with 
potential,  positive  Fayoff  for  the  SPLICE  project.  It  is 
important  to  note  that  the  EDS  can  only  improve  system 
productivity  and  accuracy  if  its  design  potential  is 
exploited.  As  a  minimum,  it  must  indicate  what  and  where 
data  is  stored,  when  and  how  updates  are  handled  and  which 
applications  programs  are  accessed.  A  DDS  implemented  to 
perform  these  functions  clearly  provides  a  great  deal  of 
automated  system  control. 
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Naturally  there  are  some  drawbacks  in  employing  a  jZS. 
A  DCS  implies  system  overhead  and  maintenance  as  well  as  ar. 
initial  harden  on  database  management  personnel.  However, 
proper  planning  and  early  organization-wide  commitment  to 
managing  data  as  a  resource  will  create  a  climate  in  which 
an  active  EDS  can  facilitate  orderly  data  processing  while 
avoiding  chaotic  data  management.  A  DDS  can  be  a  valuable 
tool  in  the  management  of  distributed  data  for  the  SELIC2 
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